"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)

"Loading" a protocol, which is what we generically call the process to
do everything required to get it to run, can now fail. We didn't think
about this failure mode, and if it happened then we would have created
some but not all of our run tracking resources, and our API would return
inconsistent results (which is the bug). The orchestrator store would
save the orchestrator object in a member, which then means that it would
have a "current run", but since we didn't link resource allocation (or
at least binding) and initialization, the exception raised after that
happens would mean it never went into the database.

The immediate fix is to not bind the orchestrator object to the
_orchestrator data member until right before we return, after we do all
the possibly-failing orchestration.

The thing that would make this fail is to have a python protocol that
was syntactically correct (passes ast.parse()) but did something at the
file scope that would cause an error (like an import failure - a
division by 0 would work too). This will fail when we exec the protocol
to check for the presence of runtime parameters, which happens during
the execution of this function, triggering the bug.

Luckily this is one of those "the error is presented badly" type of
problems so it doesn't have to be prioritized.

Closes EXEC-1450

(cherry picked from commit fe8d402)